Labelled Variables in Logic Programming: A First Prototype in tuProlog

We present the first prototype of Labelled tuProlog, an extension of tuProlog exploiting labelled variables to enable a sort of multiparadigm / multi-language programming aimed at pervasive systems. 1 Context & Motivation To face the challenges of today pervasive system, which are inherently complex, distributed, situated [7] and intelligent, suitable models and technologies are required to effectively support distributed situated intelligence. To this end, in this paper we investigate a logic programming (LP) extension based on labelled variables, and test it by means of a prototype rooted in the tuProlog system [3, 9], called Labelled tuProlog. Our general aim is to define a unique blend of LP and labelled variables – a sort of multi-paradigm and multi-language programming framework for a distributed environment – where diverse computational models can be tailored to the local needs of situated systems by means of suitable labelled variables systems, and work together against the common LP background according to the original tuProlog aim [3]. Our work builds upon the general notion of label defined by Gabbay [4], and adopts the techniques introduced by Holzbaur [6] to develop a generalisation of LP where labels are exploited to define computations in domain-specific contexts, while retaining the conventional syntax of LP. More generally, our work moves from the observation that pervasiveness of today systems requires awareness of the environment as well as the ability of reacting to changes. This mandates for models promoting system intelligence, and for technologies making it possible to spread intelligence wherever needed. While logic-based approaches are natural candidates for intelligent systems, a pure LP approach seems not to fit the needs of situated systems. Instead, a hybrid approach would make it possible to exploit LP for what it is most suited – symbolic computation –, while possibly delegating other aspects (such as situated computations) to other languages, or to other levels of computation. This is precisely where the notion of labelled variables can be of help: by enabling some parts of the computation to be expressed at a separate level, while retaining the general coherence of the LP approach. Being light-weight, intentionally designed around a minimal core, and Javabased, tuProlog is an ideal candidate to support the above goal—distributing situated intelligence while supporting labelled-variable-based computations. 2 Calegari, Denti & Omicini While several works exists in this area – such as [8, 1] – they mostly focus onto specific scenarios and sorts of systems—e.g. modal logic, deductive systems, fuzzy systems, etc. Instead, our model aims at providing a general-purpose mechanism that could fit several relevant context-specific systems, while seamlessly rooted in the LP framework. While in our first prototype labels are only applied to variables – and not generally to formulas like in Gabbay [4] – the proposed notion of label is already general enough to capture Holzbaur’s attribute variables [6], opening the way towards the expressiveness and the computational power of Constraint Logic Programming (CLP) [10, 5]—which is why the two case studies presented below assume CLP as the reference label domain. 2 The Labelled Variables Model in Logic Programming A Labelled Variables Model for Logic Programming is defined by: – a set of basic labels b1,. . . , bn, each with the form of a logic term, which represent entities in the domain of labels; – a set of labels, each defined as a set of basic labels—i.e., li = {b1i, .., bni}; – a labelling association 〈v, l〉, associating label l to variable v: as a convenient shortcut, such association can be written as v; – a combining function fL, synthesising a new label from two given ones, combining the two labels according to some scenario-specific criteria. The unification of two labelled variables is represented by the extended tuple (true/false, θ, label) where true/false represents the existence of an answer, θ represents the most general substitution, and label represents the new label associated to the unified variables defined by the combining function fL. Figure 1 reports the unification rules for two generic terms T1 and T2: to lighten the notation, undefined elements in the tuple are omitted—i.e., labels or substitutions that do not exist/do not apply in a particular situation. Since, by design, only variables can be labelled here, the only case to be added to the standard unification table is represented by labelled variables. Fig. 1. Unification rules summary Labelled Variables in Logic Programming: A First Prototype 3 While this choice clearly confines the impact of labelling, keeping the label computational model well separate from the LP one, it is also too restrictive in practice: in fact, application scenarios often need to express some relevant properties via by suitable terms, so that they can influence the label computation. For this purpose, we introduce the notion of label-interpreted terms, as a set of semantically-relevant terms in the domain of labels, along with a pre-processing phase, where each label-interpreted term is intercepted and replaced with an anonymous variable labelled with that term. In this way, any special term in the domain of label can be treated normally by the fL combining function, with no need to change the basic model above. 3 Prototype in tuProlog In this Section we apply our model in the context of the tuProlog system, designing a tuProlog extension that enables users to define their own labelled applications for their specific domains of interest. 3.1 System architecture Since tuProlog is Java-based, a language extension can be provided both as a Prolog meta-level or library, or via suitable Java methods [3]. We support both ways, defining first a Prolog-language level to denote labelled variables, then two language extensions (Prolog-based and Java-based) to be used in alterative to denote the labelled application (Subsection 3.2). Moreover, practical reasons suggest to avoid the proliferation of anonymous variables in the pre-processing phase, since they would pollute the name space and make the code less readable: for this reason, the prototype adopts a language shortcut to specify the label of a term directly, with no need to actually replace terms with unbound variables explicitly. However, this is just a linguistic extension – not a model extension –, thus leaving the model properties untouched. 3.2 The language extension In order to enable users to define their labelled application, a suitable set of Prolog predicates / Java methods is introduced to let users define: (i) the label/variable association; (ii) the function fL that specifies under which conditions two labels unify in the selected domain, returning the new label associated with the unified term; (iii) a shortcut for the pre-processing transformation, moving label-interpreted terms to the label world, making them labels of undefined variables. For the sake of brevity, we show here how to express the three entities just on the Prolog side only—the Java side being conceptually identical. – the label/variable association is expressed by the label associate(+Var, +Term ) predicate, which associates variable Var to label Term ; as a further convenience, the °/2 infix operator is also provided for the same purpose. 4 Calegari, Denti & Omicini – the function fL is expressed by the label generate(+Label1, +Label2, -Label3 ) predicate, which encodes how to build a new label from two given ones. – the pre-processing phase is embedded in the label interpret(+Label, +Term ) helper predicate, which succeeds if Term can potentially be unified with the label Label in the label world, or fails otherwise. Only if the check succeeds, the labelled variable is actually unified with the term.